This project is an illustration of how Model-Driven Engineering tools and techniques can help in other model-based fields such as scientific activities (Agronomy in our case study).
Here are some typographical conventions :
In terms of modeling capabilities:
In terms of interoperability with other models:
In terms of semantic/execution/simulation:
In this section we provide some element to understand the kind of modelssc that scientific entities such as INRA manipulate daily.
Here’s the list of inputs we had:
|
|
More can be found (in French) here. |
Pour la partie description hiérarchique, on utilise une approche systémique basée sur la connaissance du domaine (exemple on met ensemble les processus qui relèvent du bilan hydrique de la plante) et le niveau d’interaction. La profondeur de décomposition est fonction des attentes du modélisateur et des habitudes. On s’appuie aussi sur les propriétés DEVS (formalisme sous jacent).
This section describe the modeling experiments.
THe basic documents (in addition to the one presented before) is the following : documents/ModèleExploitationAgricole.pdf
There are several ways to tackle the problem.
We can follow [IDM12] metamodeling process:
We can also follow [MDSEP12]:
Parler du papier de [Selic07] pour l’approche profil du CEA LIST. CF. cette figure.
Abstract syntax for a new language
The idea behing this approach is that there will be some benefits in the use of the UML™ standard. Hence the DSL will be based on UML™ by using the profile mechanisms.
As illustrated in this figure, here is the processus we can follow:
Starting from the expected DSL (most of the time a modelsc or a graphical
représentation) and a description of the domain model (modelmde)
A domain modelmde is more precisely defined (e.g. a class diagram such as Main concepts of the domain model)
activities The concepts (e.g., Farm in Main concepts of the domain model) are mapped to the
more suitable UML™ elements (e.g., Class in Mapping concepts with UML metamodel to define a profile)
If the concepts directly match UML™ concepts (or if there is a way to slightly modify them so that they match) then it is possible to define a profile. (see e.g., Mapping concepts with UML metamodel to define a profile)
Else another solution (e.g., defining a metamodel from scratch) should be studied.
It is time then to "customize" the DSML to make it as close as possible as the user domain representation.
|
|
There are different ways of defining the domain model:
|
The above process is iterative. The constructs are introduced by step.
The profile is experimented in a modelsc importing the profile so that the user can validate
that the concepts are captured adequatly.
This is were the UML™ expert can use tuning possibilities.
The next steps consist in:
Working on the concrete syntax:
|
|
|
The profile is defined:
period in this figure)|
|
Using ecore, the process consists in startin from scratch, from an empty
metamodel. The domain model is then define "by construction".
In the UML profile approach we start with an existing (complete) metamodel
and the profiling activity consist in restricting it to specific elements.
In this approach the assumption is that their is a benefit in having both
additional concepts and tooling, notably in terms of extensibility mecanisms
and scalability.
|
Let us illustrate the need for a specific concrete syntax.
|
|
|
(by Pascal Dayre): we need to explore complex agro-system dynamic. More information with Helene’s presentation http://devlog.cnrs.fr/idm2013 (vidéo, slides)
(by Pascal Dayre) DEVS n’est pas un langage cible mais un formalisme mathématique qui permet de modéliser les systèmes selon le paradigme événementiel discret. C’est le formalisme englobant qui permet de formaliser les intéractions entre les sous-composants d’un modèle et ceci de manière hiérarchique (sous-modèle de sous-modèle, etc…). DEVS est implémenté par le langage VLE. Les spous-comosants d’un modèle est lui implémenté avec d’autres approches formalisées ou mathémathique pour des systèmes qui ont un comportement "continu", équations au différence (c’est la démo lors de la visio), d’autres composants pourraient a priori avoir un comportement décrit par un réseau baysien, etc. Par contre, si on se trouve dans un cas discontinu, on retombe dans le formalisme DEVS pour redécouper en sous-comosant continu avec la déclaration des événements entre sous-composants (modèle atomique au sens DEVS). Donc, le langage VLE implémente ce formalisme DEVS en gérant un bus inter-composants. Il offre des passerelles vers d’autres logiciels R, etc… et permet de programmer ses propres comportements en langage C++.
Il offre donc un framework: je ne trouve pas dans la doc de description général de ce framework, ni la grammaire du langage. Peut-etre qu’Helene a une info, un contact. Par contre:
Le Langage cible est le langage VLE:
DEVS abbreviating Discrete Event System Specification is a modular and hierarchical formalism for modeling and analyzing general systems that can be discrete event systems which might be described by state transition tables, and continuous state systems which might be described by differential equations, and hybrid continuous state and discrete event systems. DEVS is a timed event system.
DEVS is a high level formalism that has the ability to encapsulate other formalisms. VLE allows you to use several formalisms in DEVS framework:
Document réalisé par Jean-Michel Bruel, Benoît Combemale (bruel@irit.fr,benoit.combemale@irisa.fr) via Asciidoctor (version 1.5.1) de 'Dan Allen', lui même basé sur AsciiDoc.
Pour l’instant ce document est libre d’utilisation et géré par la 'Licence Creative Commons'.
licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.
/